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Status of the prosecution 

20 Examiner mailed a final Office action in the above patent application on 9/19/2007 in 
which she rejected all claims under 35 US C. 1.03(a) as obvious over the combination of 
USSN 6,067,540, Ozbutun, et al.. Bitmap segmentation, issued May 23, 2000 (hereinafter 
"Ozbutun") and U.S. Patent 6,026,398, Brown, et al., System and method for searching 
and matching databases, issued Feb. 15, 2000 (henceforth "Brown"). Applicants 

25 traversed the rejection in a response mailed 12/18/2007 and Examiner responded in an 
Advisory Action mailed 1/16/2008 in which she persisted in her rejection. Applicants are 
now responding with a Request for a Pre-Appeai Brief Conference and the following 
Brief, fa the Brief, locations in Applicants' Specification are cited using the paragraph 
numbers from the published application, which bears the publication number US 

30 2005/021.65 IS 

What Applicants are claiming 

As set forth in Applicants' Abstract, Applicants' inventions concern techniques for 
35 making bitmap values in database systems more useful than they presently are. Bitmap 
values have long been used in the bitmap indexes which database systems provide to 
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users, but users of database systems which employed bitmap indexes could do no more 
than specify that the database system make a bitmap index for a field of a table or drop 
such an index. All of the operations necessary to create, maintain, use, and delete the 
bitmap indexes were automatically .performed by the database system. See [0017]- 



5 [0020] of US 2005/021651 S In Applicants 1 inventions, by contrast, the user can directly 
define and manipulate bit-map values that represent sets of objects whose definitions are 
built into the database system. An example of such objects is row identifiers. Claim 1 
sets forth one aspect of the invention: 

1 1. (currently amended) A database management system having the 

2 improvement comprising: 

3 bitmap values, a bitmap value having a representation of a bitstring 

4 wherein set bits specify a set of objects whose definitions are built into the 

5 database management system, and 

6 bitmap operations provided by the database system, a bitmap 

7 operation having user-specified operands which are bitmap values and/or 

8 sets of objects. 

10 The limitations of lines 6-8 of claim .1 clearly distinguish the claim from the prior art of 
[0017]-[0020J. As will be shown in the following, they also clearly distinguish the claim 
from the disclosures of Ozbutun and Brown. 



The disclosures of Ozbutun and Brown 

1 5 Ozbutun 

The Ozbutun reference is primarily concerned with dividing bitmap indexes into 
segments in order to reduce the size of the indexes and to reduce the granularity of 
operations such as compression, de-compression, locking, and logging which the 
relational database system automatically performs in the course of using and maintaining 

20 bitmap indexes (Ozbutun, Abstract), There is simply no disclosure anywhere in Ozbutun 
which indicates that users have access to primitive operations on the bit map indexes. In 
her rejection of claim 1, Examiner cites FIG. 3A, col, 5, lines 58-67, col. 6, lines 20-26, 
and col. 7, lines 4-21 as showing the claimed "bitmap operation having user specified 
operands". FIG. 3 A show's a table and FIG 3B shows a segmented version of a standard 

25 prior-art bitmap index. Col. 5, lines 58-67 describes the figures; col. 6, lines 20-27 
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describes how if all of the indexed .fields in a segment of a segmented bitmap have the 
same value, the segment will merely specify the range and the value. There is no 
indication in Ozbutun that a user can specify that a bitmap index be segmented or that the 
user can specify how it will be segmented. 

5 

Col. 7, lines 4-21 sets forth how segmenting a bitmap index speeds up operations 
involving the bitmap index. The described operations are, however, all operations that 
the relational database system automatically performs on the bitmaps in the course of 
using the bitmaps in query operations; none of them is "a bitmap operation having user 
10 specified operands", as required by the claim. 

In her Advisory Action, Examiner rebuts the foregoing by stating that col. 6, lines 40-56 
teaches that the user may specify segmentation of bitmaps. The cited location, however, 
merely sets forth that "Database systems may avoid many of the problems associated 
1 5 with the maintenance and use of bitmaps by segmenting bitmaps in the manner described 
above" and then explains how segmenting bitmaps improves locking granularity. 
Nothing in the cited location suggests that the user may specify segmentation of bitmaps. 

Brawn 

20 The first sentence of Brown's Abstract gives a good overview of the reference's 
disclosure: 

In a database data processing system, input search data is matched against 
an index of a database to determine database records which either closely 
or exactly match the input search data. 

25 

As one would expect from the above. Brown is only marginally concerned with bitmap 
indexes. They appear in Brown's disclosure only as one of the many kinds of indexes 
which may be used in Brown's system. The total disclosure concerning bitmaps in 
Brown consists of the following: col. 2, lines 20-34, which describe the use of bitmaps in 
30 inverted indexes, and col. 5, lines 1-8 and col. 11, lines 22-37 together with FIG. 15, 
which describe how bitmaps may be used to identify the database records to which a term 
set relates. 
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Examiner cites none of the disclosure concerning bitmap indexes in Brown. Instead, she 
cites to col. .14, lines 36-58, which must be understood in the context of the "flowchart of 
match e i lown in FIG. 7" (col. 9, lines 38-39), In overview, what the 

5 flowchart of FIG 7 shows is how input data which is to be matched with records in a 
database is received (30), parsed into its elements (31), and is converted to terms 
belonging to a predetermined set of terms used in the database system (33). The terms 
resulting from the conversion are matched to records in the database system, with indexes 
being used in the matching (35). The indexes may of course be bitmap indexes. Once 

10 the records matching the terms have been returned, the records are filtered as shown in 
steps 36-40 to determine which records best match the criteria specified in the input data. 
The filtering is described beginning at coi. 12, line 21. There are three stages to the 
filtering: by record weight (36), by applying a function to the results of the filtering by 
record weight (37), and if that function does not produce a match (38), applying a third 

1 5 function (40). 

Col, 14, lines 36-58 cited by Examiner are part of the discussion of step 37. FIG, 11 is a 
list, of the tests applied to the weights of the records received from the first stage of the 
filter. The meanings of the symbols used in the list are explained in the box labeled 

20 "Legend". As can be seen there, the tests involve record weights C from the first stage 
of the filter, record weights W from the second stage of the filter, constants K, and the 
mathematical mean, sum, min, abs, and sqrt operations. None of these functions have 
"user-specified operands" (the operands are the records which are the results of the first 
stage of the filtering), and even more to the point, none of these functions involve 

25 bitmaps either as operands or as results. Consequently, none of these functions can be 
taken to be the "bitmap operation" of the claim. 

Independent claims 22, 36, and 44 

These claims all include limitations involving bitmap operations which may be 
30 performed by users of the database system. As pointed out above with regard to claim 1, 
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the references do not disclose such operations, and consequently, the references cannot be 
combined to reject claims 22, 36, and 44 under 35 U.S.C. 103. 

Patentability of the claims over the references 

5 As just demonstrated, neither Ozbutun nor Brown discloses claim 1 's limitation 



1 0 or the analogous limitations of claims 22, 36, and 44. 

Because that is the case, Examiner has not made the prima facte case of obviousness 
required by MPEP 2142 and her rejection of claims 1, 22, 36, and 44 under 35 U.S.C. 
103(a) is without basis. Further, because all of the independent claims are patentable 
over the references, so are all of the dependent claims. Applicants consequently 
15 respectfully request that the Conferees reverse Examiner's rejection of the claims and 
return the application to Examiner with instructions to allow the claims and pass the 
application to issue. 



bitmap operations provided by the database system, a bitmap operation 
having user-specified operands which are bitmap values and/or sets of 
objects 
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